home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 1045 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.9 KB
  1. Path: herold.franken.de!jhd
  2. Date: 08 Jan 1996 19:35:00 +0100
  3. From: jhd@herold.franken.de (Joachim Durchholz)
  4. Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.modula2,comp.lang.modula3,comp.lang.smalltalk
  5. Message-ID: <60SqRiBF3RB@herold.franken.de>
  6. References: <cmanDK7x13.5KM@netcom.com> <30e26364.2569895@news1.wolfe.net>
  7.     <4bvae4$fl6@beatty.slip.netcom.com> <4c0a6d$4hs@news.irisa.fr>
  8.     <4cnmqu$2fg@beatty.slip.netcom.com>
  9. Subject: Re: whither style
  10. X-Newsreader: XP v3.02
  11. MIME-Version: 1.0
  12. Content-Type: text/plain; charset=ISO-8859-1
  13. Content-Transfer-Encoding: 8bit
  14.  
  15. Jeez, there are so many points here I'd like to give my 2c worth of I  
  16. can't resist.
  17.  
  18. beatty@netcom.com wrote 07.01.96 on Re: whither style:
  19.  
  20. > As to scope, surely if you're smart enough to use Eiffel you're not using
  21. > global variables, or at least not very many of them, or at least not without
  22. > some clear way to distinguish them.  Actually, I'm a bit surprised that
  23. > Eiffel has global variables, but you brought them up.
  24.  
  25. There is definitely no such thing as a global variable in Eiffel.
  26.  
  27. > >close to its uses. And if your program unit is longer than a few
  28. > >tens of lines (which is poor style in e.g., Eiffel)...
  29. >
  30. > from printed listings.  And yes, a good environment will show me a
  31. > variable's type just by clicking on it, but with HN I know the type just by
  32. > *looking* at it, and looking is even easier than clicking.
  33.  
  34. Good code is so short you see the declaration at a glance. And if I'm  
  35. discussing lengthy code in an environment where I don't have an  
  36. environment that shows me the declaration, then I just include it with the  
  37. code. True, HN has its use there, but rather as a means of abbreviation.
  38.  
  39. > Were that to be done, this thread would die just when it is becoming more
  40. > interesting.  The assertion has been made that language and technology
  41. > better solve the problem that HN attempts to address.  I disagree because I
  42. > prefer three tools to two (and I'm not convinced that language is relevant
  43. > at all).
  44.  
  45. I prefer one good tool to a dozen of inappropriate ones.
  46.  
  47. I think HN is inappropriate for languages where you can change the  
  48. representation of a type behind the scenes, simply because it's impossible  
  49. to invent an abbreviation for every type that shows up in a project.
  50.  
  51. In my experience, such languages actually don't need HN; the compiler will  
  52. catch all errors that HN is supposed to help avoid. This is because in  
  53. these languages, the type of a variable or value precisely defines what  
  54. operations are admitted for it. If you had a type zero-terminated-string  
  55. in such a language, the compiler won't allow you to pass this to a routine  
  56. that expects a string with a length descriptor.
  57.  
  58. For languages that have a more loose relation of types and routines,
  59. you need to have some fast way of checking wether an operation is  
  60. applicable. HN makes that check easier, so it has a point there.
  61.  
  62. -Joachim
  63.  
  64. --
  65. Im speaking for myself here.
  66. ## CrossPoint v3.02 ##
  67.